As more and more functionality is getting integrated into system-on-chip (“SoC”) designs, there is a steady increase in the usage of 3rd party IP (e.g., Arm IP). Arm IP with memories generally has one or more Arm MBIST interfaces. The MBIST interface allows access to each memory through a sensitized functional path. This methodology moves the MBIST multiplexer away from the memory interfaces, which are often critical paths, reduces routing around each of the memories, as the functional path into the memory is reused, and allows an at-speed test from a functional register to the memory bit-cell during MBIST. These IPs contain one or more MBIST interfaces that internally consist of multiple logical arrays (e.g., memories). Each logical array (see e.g., FIG. 1) itself consists of one or more physical memories (see e.g., FIGS. 2-4), or slices of physical memories. The choice of physical memory organization for a given logical array is made by end customers based on design implementation targets and memory compilers.
Arm IP deliver MBIST information files (“MBIFs”) with each IP which contains one or more MBIST interfaces. MBIF contains an electronic description of each unique Arm MBIST interface.
IP is configured during design implementation by the end customer. Organization of random access memories (“RAMs”) for any given logical memory is also an end customer choice and could be done in more than one way during design implementation of the IP. The information provided in the MBIF describes only the logical arrays. The information for the connections from the logical arrays to the physical arrays must be created during implementation as there is more than one way of making physical RAM choices for a given logical array by an end customer. The MBIST insertion process requires additional information on how the physical memories are organized behind logical memories to ensure high quality testing. The information of physical organization is only available with the end customer and cannot be covered in the MBIST information file. This makes it very critical to have a technique to automatically determine all physical memories in the core (e.g., in order to test and validate that all physical memories are functioning properly), their association with the logical memories described in the MBIF and their associated enabling signals.
The complexity of the problem can be seen in the examples shown in FIGS. 1-4. FIG. 1 shows a logical memory (e.g., consisting of 94 words where each word is 100-bits wide). FIGS. 2-4 are possible implementations of the same logical memory where FIGS. 2 and 3 implement the logical memory using 3 physical memories of varied sizes while FIG. 4 implements the same logical memory using 6 physical memories. These memories are accessible via the IP boundary through an MBIST specific macro interface. Moreover, each macro interface may consist of multiple logical memories.
Each logical memory is accessed with different decode values of some array select signals. There may be varying number of pipeline stages from the test interface boundary to these logical memories. As it can be seen that a single logical memory may be constructed from a varying number of complex physical memory configurations, the problem then becomes magnified by the added complexity of multiple logical memories accessed through the same interface.
FIG. 5 shows a simplistic version of a core 500 with just single MBIST interface which contains 4 logical arrays 505 where each logical array contains 2 physical memories 510. The cores may have multiple interfaces. These physical memories may be tested from a macro interface boundary. Given the name of the macro interface, it is not at all easy to figure out all the underlying physical memories and their enabling signals because the same core may be configured in different fashion by different users of the core. And if this cannot be done properly or accurately then the memories cannot be tested which impacts quality and leads to field returns.
Thus, it may be beneficial to provide an exemplary system, method, and computer-accessible medium for automated identification of embedded physical memories using shared test bus access in intellectual property cores, which may overcome at least some of the deficiencies presented herein above.